<?xml version="1.0" encoding="utf-8"?>
<Content xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="urn:blueonionsoftware-com:bloget:runtime:data">
  <text>From a microsoft &lt;a href="http://blogs.msdn.com/arich/archive/2004/09/29/235959.aspx"&gt;web blog&lt;/a&gt;

&lt;strong&gt;C++ users&lt;/strong&gt; are already intimately familiar with the concept of Disposable types.  In fact, that's really what we know best - this whole indeterministic cleanup thing is a little strange, for us.  So, in Whidbey, we expose Dispose() the way C++ users will best understand it - through the destructor.

&lt;strong&gt;Hold on, didn't the destructor expose the finalizer?&lt;/strong&gt;  In Everett (and old syntax Whidbey), yes.  And it's unfortunate that we've changed the meaning of it.  All I can say is that we wouldn't change it if we didn't have a very good reason.  (I think that we do.)  We now expose the finalizer through a new construct, the "bang" destructor:

&lt;code&gt;    ref class myClass {
      ~myClass(){} //Dispose(), myClass implicitly implements System::IDisposable
      !myClass(){} //Finalize()
    };
&lt;/code&gt;

&lt;strong&gt;So, is it just a syntax change?&lt;/strong&gt;  No.  We've also implemented deep destruction semantics.  That is to say, my destructor will call my base classes' destructor, just like in standard C++.  The compiler accomplishes this by injecting the call.  Just like in native C++, the destruction is stack-ordered, so the first object constructed will be the last destructed.  It's important to point out that we are not leveraging the CLR to accomplish this.  So, this destructor chaining is going to work for all C++-built code.  You can't assume that because you're consuming a C++ class from C# that you won't get the destructor-chaining behavior, because you will - it's in the code.  And I believe that's the right decision; changing the destruction semantics of a class you didn't create has unknown ramifications.

&lt;strong&gt;Using the C++ DF&lt;/strong&gt; model then becomes pretty straightforward.  (A little more straightforward than using the CLR Dispose() pattern, I think.)  If you want deterministic cleanup, you put it inside your Disposer, or you can use a Finalizer for non-deterministic cleanup.

&lt;strong&gt;The call to GC::SuppressFinalize() &lt;/strong&gt;is also taken care of for you, by the compiler.  A call to GC::SuppressFinalize(this) is injected into the destructor.  What this means is that you'll either get your destructor called, or your finalizer, but never both.  This is important to remember when designing your cleanup.

&lt;strong&gt;There's still plenty more discussion for C++ DF.&lt;/strong&gt;  Part III will discuss how the C++ and CLR disposal patterns interact, and Part IV will get to the really interesting stuff: how the C++ DF model can provide you with significant benefits.</text>
  <last_update>2007-10-04T00:52:10.0350806Z</last_update>
  <source_title />
  <source_link />
  <comments />
  <references />
  <attachments />
</Content>